
A Laser Communications Terminal consists of the optical head on a 2-axis gimbal (left), and an elec- 
tronics/laser box (right). 


able include laser transmit power at 
either end of the link, and telescope 
aperture diameter at each end of the 
link. Increased laser power is traded 
for smaller-aperture diameters. 

5. Use of commercially available space- 
qualified or qualifiable components 


with traceability to flight qualifica- 
tion (i.e., a flight-qualified version is 
commercially available). An example 
is use of Telecordia-qualified fiber 
optic communication components 
including active components (lasers, 
amplifiers, photodetectors) that, ex- 


cept for vacuum and radiation, meet 
most of the qualifications required 
for space. 

6. Use of CWDM technique at the flight 
transmitter for operation at four 
channels (each at 2.5 Gb/s or a total 
of 10 Gb/s data rate). Applying this 
technique allows utilization of larger 
active area photodetectors at the 
ground station. This minimizes atmos- 
pheric scintillation/turbulence in- 
duced losses on the received beam at 
the ground terminal. 

7. Use of forward-error-correction and 
deep-interleaver codes to minimize at- 
mospheric turbulence effects on the 
downlink beam. 

Target mass and power consumption 
for the flight data transmitter system is 
less than 10 kg and approximately 60 W 
for the 400-km orbit (900-km slant 
range), and 12 kg and 120 W for the 
2,000-km orbit (6,000-km slant range). 
The higher mass and power for the latter 
are the result of employing a higher- 
power laser only. 

This work was done by Joseph M. Kovalik, 
Hamid Hemmati, Abhijit Biswas, and 
William T. Roberts of Caltech for NASA 's Jet 
Propulsion Laboratory. Further information 
is contained in a TSP ( see page 1 ). NPO- 
48413 
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The Application Programming Inter- 
face (API) for the Crew Exploration Ve- 
hicle (CEV) Aerodynamic Database has 
been developed to provide the develop- 
ers of software an easily implemented, 
fully self-contained method of accessing 
the CEV Aerodynamic Database for use 
in their analysis and simulation tools. 
The API is programmed in C and pro- 
vides a series of functions to interact with 
the database, such as initialization, select- 
ing various options, and calculating the 
aerodynamic data. No special functions 
(file read/ write, table lookup) are re- 
quired on the host system other than 
those included with a standard ANSI C 
installation. It reads one or more files of 
aero data tables. 

Previous releases of aerodynamic 
databases for space vehicles have only 
included data tables and a document of 
the algorithm and equations to com- 
bine them for the total aerodynamic 


forces and moments. This process re- 
quired each software tool to have a 
unique implementation of the database 
code. Errors or omissions in the docu- 
mentation, or errors in the implemen- 
tation, led to a lengthy and burden- 
some process of having to debug each 
instance of the code. Additionally, 
input file formats differ for each space 
vehicle simulation tool, requiring the 
aero database tables to be reformatted 
to meet the tool’s input file structure 
requirements. Finally, the capabilities 
for built-in table lookup routines vary 
for each simulation tool. Implemen- 
tation of a new database may require an 
update to and verification of the table 
lookup routines. This may be required 
if the number of dimensions of a data 
table exceeds the capability of the simu- 
lation tool’s built-in lookup routines. 

A single software solution was cre- 
ated to provide an aerodynamics soft- 


ware model that could be integrated 
into other simulation and analysis 
tools. The highly complex Orion aero- 
dynamics model can then be quickly in- 
cluded in a wide variety of tools. The 
API code is written in ANSI C for ease 
of portability to a wide variety of sys- 
tems. The input data files are in stan- 
dard formatted ASCII, also for im- 
proved portability. 

The API contains its own implementa- 
tion of multidimensional table reading 
and lookup routines. The same aerody- 
namics input file can be used without 
modification on all implementations. 
The turnaround time from aerodynam- 
ics model release to a working imple- 
mentation is significantly reduced. 

This work was done by Philip E. Robinson 
and James Thompson of Johnson Space Cen- 
ter. For further information, contact the JSC 
Innovation Partnerships Office at (281) 483- 
3809. MSC-2481 9-1 
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